<h1><join>Writing Test Suites in LISP</join></h1>
<h2>Context</h2>
<p>
Two issues with sharing code are: 
<ul>
  <li>Explaining your code to other people; 
<li>Making sure that your new changes does not break
  existing code.
  </ul>
<p>  <em>Unit tests</em> are a useful way to address these issues. A unit test is a canned 
example that runs some functions. The outputs are automatically compared to 
some expectation in order to see if a test has passed or failed the tests. 
<p>
Unit tests are also very useful when writing your own code. Authors like Kent 
Beck argue that software development should be structured around building and 
running unit tests. Test-driven development (TDD) requires the programmer to 
ﬁrst fail the test cases. The idea is to ensure that the test really works and can 
catch an error. Once this is shown, the normal cycle will commence. This has 
been coined the ”Test-Driven Development Mantra”, known as red/green/refac- 
tor where red means fail and green is pass. 
In a <a href="http://en.wikipedia.org/wiki/Test_driven_development"pure TDD approach</a>,
  work proceeds as follows :
  <ul>
    <li>
Planning rules:
    <ul>
      <li>
User stories are written. (a.k.a. lots of tests); 
<li> Make frequent small releases (a.k.a. shows a string of tests); 
<li> Fix the program only when it breaks (aak.a. code-run-break-ﬁx is the 
usual cycle).
      </ul>
      <li>
Coding rules:
  <ul><li>     Code the unit test ﬁrst. 
</ul>
<li>Testing rules: 
<ul><li> All code must have unit tests. 
<li>All code must pass all unit tests before it can be released. 
<li>When a bug is found tests are created. 
<li>Acceptance tests are run often and the score is published. 
</ul>
</ul>
<h2>Deftest</h2>
<p>
We offer here  an adaption of
<a href="http://gigamonkeys.com/book/practical-building-a-unit-test-framework.html">
Peter Seibel’s  unit testing code</a>. The <t>deftest</t> function defined a new test
and the <t>tests</t> macro runs a bunch of tests, the prints the number of passes and fails.
For example, the following code defines a function <t>test-bell</t> that
checks that the function <t>(bell!)</t> returns a distribution
structure containing a bell shaped curve:
<pre>
(deftest test-bell! ()
  (check
    (samep "#S(DIST
               :BUCKETS ((1 . 0.0)     (2 . 0.0)     (3 . 0.0625) (4 . 0.15625) ( 5 . 0.28125)
                         (6 . 0.28125) (7 . 0.15625) (8 . 0.0625) (9 . 0.0)     (10 . 0.0))
               :CARDINALITY 10
               :MIN 0
               :MAX 100)"
           (bell!))))
</pre>
<p>(The <t>samep</t> function compares two strings after removing all white space- so the
test result can be laid out pretty without mucking up the test.)
<p>At the time of this writing, the code has six <t>deftest</t>s. We can run them all as follows:
<pre>
CL-USER> (tests)
......
PASSES: 6 (100 %)
FAILS : 0
NIL
</pre>
Which is to say that we ran six tests and none of them failed.
<p>Hint: it is useful to write unit tests are written in a hierarchy. If some nested test is called 
within a super-test, then the code recurses into sub-tests. In this way, so cen- 
tralized test facility can be deﬁned in terms of multiple layers of tests spread 
through out in multiple files across the entire code. 